At least 85 percent of hardware designed today using HDLs (Verilog and VHDL) is designed at the register-transfer level. Many design teams are finding that RTL descriptions with HDLs are at or beyond their limit for handling the size and complexity of today's designs. The issues include simulation times that are too long, verification solutions that are too complex and design complexity that is too large to describe at the register-transfer level. Many of our students are exploring how to describe their designs at a higher level of abstraction to enable faster simulation, to enable hardware/software co-description and co-simulation, and to enable them to get their arms around the design. The higher levels of complexity in today's and tomorrow's system-

on-chip designs will force a move to higher levels of abstraction to break through the simulation and verification bottleneck.

Verilog and VHDL work well as HDLs but are poor programming languages. They were never intended for testbench generation and testing, although many designers have used them that way. C++-based design provides a single-language solution that covers system-level design and hardware description as well as testbench generation and testing.

In many design flows, system architects use C or C++ to define the overall system. When it is time to create hardware, design engineers use an error-prone, manual process to convert the C or C++ description to Verilog or VHDL. Or they do not convert the C/C++ model, but simply write an HDL model. This creates a disconnect between the system and HDL models. It requires co-simulation and multiple system tests to verify that the translation is accurate. Because it is a difficult and tedious task, many design teams either don't verify the HDL model against the C/C++ model at all, or if they do, the checking is not rigorous. For that reason, most projects tend to drop or not maintain the C/C++ model and use the HDL model as the reference source.

With a C++-based flow, there is no longer a barrier between the system-level description and the hardware implementation. The specification created by the system architect is no longer just a paper spec. It is an executable model for the hardware design team. The hardware design process becomes a refinement of the specification rather than a disjointed translation.

The system architect's specification also drives the software portion of the system. To trade off what to implement in hardware vs. what to implement in software, designers must use co-design techniques. If the hardware designers use HDLs, they must use co-simulation to simulate the hardware in HDLs and the software in C++. If both hardware and software design are based on C++, it is easier to trade off between the two. In addition, the single-language-based simulation is faster than a multilanguage co-simulation.

Intellectual-property providers face a different dilemma. They need to determine which model to use for delivering IP at the system level, and whichever model they choose, they need to provide their customers with a complete simulation environment.

If they deliver C or C++ models, it is difficult to deliver the simulation environment. A number of IP vendors have standardized on SystemC because it provides a full hardware/software simulation environment. The IP vendor can provide a SystemC model and point to a place for the user to download-for free-everything else needed to use the model.

Alternatives to C++-based design
If your design team is facing the limits of RTLs/HDLs, the need for an appropriate verification language, nonexecutable system-level specs, or the need for a system-level IP format, will you have to learn C++? Not necessarily-or at least not right away.

Some companies are addressing one or more of those issues with C++-based languages. Others are continuing to use solutions such as manual translations and co-simulation solutions, and still others are moving to new languages including such hardware verification languages (HVLs) as OpenVera from Synopsys and e from Verisity, or extensions to HDLs like Superlog.

How do these languages compare? It depends on their purpose.

For designs that are bounded at the register-transfer level and have no software content, Verilog and VHDL are and will continue to be excellent solutions. Even as more designs begin with system-level descriptions (whether in C++-based languages or some alternative), Verilog and VHDL will continue to make sense for the refinement of the design, if not the starting point. In addition, with all the tools available for HDL design, proven design flows and a large number of engineers trained in their use, HDLs will be around for a long time to come.

Programming duds
But HDLs have their weaknesses. As we have seen, because Verilog and VHDL are not good programming languages, they are not well-suited for testbench generation and testing. HVLs were created specifically for testbench generation to fill this hole. These languages supplement but do not replace the RTLs in the design flow. To use HVLs, engineers must learn a second language for testbench generation and use co-simulation between the HDL and HVL for verification. While the HVLs are an excellent fit for verification, a multilanguage solution requiring co-simulation is not ideal.

HDLs have another weakness. They were not designed with the intent of writing system models. They are a very poor fit for hardware/software co-design and a very poor fit for modeling an entire system.

One way to address the weaknesses in HDLs without forcing designers to learn an entirely new language is by extending an existing HDL. Superlog, an extension of Verilog, is an example of this approach. Superlog adds C features to Verilog, making it a very good fit for testbench generation as well as an excellent fit for RTL design. Superlog also contains some features to allow for system-level design. The Superlog approach is very appealing to Verilog-literate hardware design engineers because it is based on a familiar language, keeping them within their comfort zone. In addition, for verification, it is a single-language, single-simulator solution. Simulating hardware and software together, however, still requires co-simulation.

How do the C++-based languages fit in? For designs that are bound at the register-transfer level with no software component, there is no compelling reason to move to C++-based languages.

A limited number of tools are available today (especially compared with HDL-based tools), and there is no performance gain in using C++ vs. HDLs for RTL designs. If your design project falls into that category, your best choice is to stick with Verilog or VHDL.

For designers working on testbench generation and testing, using a real programming language such as C++ is an excellent fit. There is a need, however, for verification libraries for C++-based languages to provide an excellent solution for verification.

System-level modeling is an area where the C++-based languages such as SystemC shine. SystemC has direct support for modeling at higher levels of abstraction and for interface-based refinement. C++ is often the language of choice for system architects because it can model the entire system. C++-based design languages enable hardware/software co-design and co-simulation, and they address the verification bottleneck when designs get too big for the RTLs/HDLs to handle. Behavioral and RTL design become refinement paths in this methodology.

But the downside of the C++-based design languages is the learning curve for the typical RTL-literate hardware design engineer.

The learning curve
How hard is it to learn C++-based design languages? We will look at SystemC to answer the question.

C++ was designed as an extensible, object-oriented modeling language. The core C++ language cannot be used to fully describe hardware for a number of reasons. SystemC extends the capabilities of C++ to enable hardware description. There are concepts in hardware design that either do not apply or play a very minor role in software programming, and therefore are either not addressed or not addressed well in C++.

One issue is the concept of time-sequenced events. A second issue is concurrency. Hardware is inherently concurrent, with various portions of the design operating in parallel. A third concept is hardware data types. For example, there is a need to be able to describe tristate logic values or an element that is an odd bit size (a 13-bit bus, for example). To address these and additional hardware modeling issues, SystemC adds a class library to extend the capabilities of C++. The class library is not a modification of the language, but a library of functions, data types and other language constructs that are all legal C++ code. SystemC provides such a class library as well as a simulation kernel.

To write and simulate a SystemC model, the engineer writes his or her model using C/C++ and functions, data types and such from the SystemC class library. The engineer then compiles the model and links it with the simulation kernel and SystemC libraries to create an executable, which, when run, becomes the simulation.

If you are an HDL designer with little or no C experience (a common state), then jumping into design with SystemC can be daunting. Based on our experience in providing SystemC, Verilog and VHDL training, the learning curve for SystemC for such an engineer is about the same as the learning curve for Verilog or VHDL for an engineer with just C or basic programming experience.

Compared with HDLs, C++ is more complex and flexible. That is the blessing and curse of C++. The flexibility of C++ allows the language to be extended for hardware design, but the same flexibility allows the designer to write perfectly legal C++ code that cannot possibly be implemented in hardware.

SystemC makes the task of learning C++ easier than it could be otherwise by providing macros, which hide some of the C++ complexity and provide the engineer with familiar concepts such as modules. Additionally, the library provides functions with familiar capabilities, such as waiting for an event (for the positive edge of a clock signal, for example).

It is the complexity that is the tough part for HDL engineers. Interestingly enough, the fundamental idea of object-oriented programming is not that difficult for them, primarily because of the correlation to ideas used in HDLs (module instance to an object, for example). Instead, the hardest parts are the new concepts and complexity associated with C++ object-oriented programming (inheritance, constructors, etc.).

Because SystemC is essentially an extension of C++ using libraries, there is another issue that is more complex than with HDLs that steepens the learning curve-that of semantics vs. syntax. When your HDL code is syntactically correct, meaning it compiles with no errors, it is pretty much semantically correct, which means your code follows the rules of use as well. Your HDL code may not simulate what you wanted or meant, but it will simulate what you told it to do.

With SystemC, this is not the case-correct syntax does not mean correct semantics. Your code may compile correctly, but that does not mean you are correctly following the rules of use for the functions and other constructs from the SystemC library. If you have semantic errors, the result can be run-time errors or worse. Your code not only doesn't simulate what you want, it doesn't even simulate what you told it. A SystemC semantic rule checker can catch those errors early and help ease the learning curve.

We are definitely seeing a move to system-level design taking place right now. It has somewhat the same feel to it as the move to RTL design in the late '80s. The speed of adoption remains to be seen. This movement has already narrowed down the field of language candidates, with C++-based solutions, and SystemC in particular, among the leading choices, along with alternatives such as Superlog.

Today, hardware design engineers need to move to system-level design. They will need to learn C++, SystemC or some other C++-based design language.

---

Mike Baird delights in all kinds of languages as president of Willamette HDL Inc. (Beaverton, Ore.), a company with value-added EDA products for engineers using SystemC. Baird holds a Master's of Science degree in electrical engineering from Brigham Young University, Utah.

http://www.isdmag.com